Skip to content

fix(ci): trigger release PR auto-merge via workflow_run instead of pull_request - #479

Merged
sebastiancorrea81 merged 1 commit into
mainfrom
fix/auto-merge-release-workflow-run-trigger
Aug 7, 2026
Merged

fix(ci): trigger release PR auto-merge via workflow_run instead of pull_request#479
sebastiancorrea81 merged 1 commit into
mainfrom
fix/auto-merge-release-workflow-run-trigger

Conversation

@sebastiancorrea81

Copy link
Copy Markdown
Collaborator

Problem

auto-merge-release-pr (triggered on pull_request) has been silently broken for a while: the release-please PR is always opened by github-actions[bot], whose author_association on this repo is CONTRIBUTOR (not MEMBER/COLLABORATOR). That's enough for GitHub's "require approval for outside collaborators" gate to treat its pull_request-triggered runs as needing manual approval — the same mechanism used for fork PRs — even though this branch (release-please--branches--main) lives in this repo, not a fork.

Evidence:

Fix

Switch the trigger from pull_request to workflow_run (on "Release Please" completing). Runs triggered by workflow_run always use the workflow file from the default branch with full permissions and aren't subject to the outside-collaborator approval gate.

Since workflow_run doesn't carry PR context, a new find-pr job resolves the open release PR itself (same lookup generate-readmes already does in release.yml) and validates its author/label before merging — this is exactly what the reusable workflow's existing pr_number input was already built for (see its description in nullplatform/actions-nullplatform), so no changes needed there.

This also removes the concurrency/cancel-in-progress workaround for the generate-readmes follow-up commit race — workflow_run only fires once the entire "Release Please" run (both jobs) has finished, so there's nothing to race against anymore.

Test plan

  • Merge this PR.
  • Merge (or wait for) the next normal feature/fix PR to main.
  • Confirm in the Actions tab that auto-merge-release-pr now fires via workflow_run, find-pr resolves the release PR, and automerge completes successfully (no action_required/queued).
  • Confirm the release PR gets merged by the bot without human intervention, and the tag/GitHub Release is published automatically.

🤖 Generated with Claude Code

…ll_request

The release-please PR is always opened by github-actions[bot], whose
author_association on this repo is CONTRIBUTOR rather than
MEMBER/COLLABORATOR. That's enough to make GitHub treat its
pull_request-triggered runs as needing manual approval (the same gate used
for outside-collaborator forks), even though the branch lives in this repo.
Evidence: every recent release PR (6.8.0, 6.8.1, 6.8.2, 6.7.1, 6.7.2) was
merged by a human, and the last two auto-merge-release-pr runs on the
release PR completed with action_required and zero jobs.

workflow_run runs use the workflow file from the default branch with full
permissions and aren't subject to that gate, and it also naturally waits
for the whole "Release Please" run (release-please + the generate-readmes
follow-up commit) to finish before firing, so the concurrency/cancel
workaround for the follow-up commit race is no longer needed either.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@sebastiancorrea81
sebastiancorrea81 merged commit 80738de into main Aug 7, 2026
45 checks passed
@sebastiancorrea81
sebastiancorrea81 deleted the fix/auto-merge-release-workflow-run-trigger branch August 7, 2026 16:20
sebastiancorrea81 added a commit that referenced this pull request Aug 7, 2026
## Problem

Follow-up to #479. Confirmed live right after #479 merged: the new
`find-pr` job ran and correctly located PR #476, but skipped it with
"Open PR doesn't match expected author/label", leaving the release PR
un-merged.

Root cause: `gh pr list --json author` is GraphQL-backed and represents
`github-actions[bot]` as `"app/github-actions"`, not
`"github-actions[bot]"`. The comparison in `find-pr` (and the reusable
workflow's `release_pr_author` default, and the old
`pull_request`-triggered version's
`github.event.pull_request.user.login`) all expect the REST-style
`"github-actions[bot]"`.

## Fix

Switch the PR lookup from `gh pr list --json author` to `gh api
repos/{repo}/pulls?state=open&head={owner}:release-please--branches--main`
(REST), whose `user.login` is `"github-actions[bot]"` as expected.
Verified locally against the real PR #476 before pushing.

## Test plan

- [ ] Merge this PR.
- [ ] Confirm in Actions that the next `auto-merge-release-pr`
(workflow_run) run resolves `pr_number` for PR #476 and actually merges
it this time.
- [ ] Confirm the tag/GitHub Release gets published without human
intervention.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
sebastiancorrea81 added a commit that referenced this pull request Aug 7, 2026
🤖 I have created a release *beep* *boop*
---


##
[6.10.0](v6.9.0...v6.10.0)
(2026-08-07)


### Features

* **service_definition:** forward link spec fields from the template
([#477](#477))
([2994e6b](2994e6b))


### Bug Fixes

* **ci:** compare release PR author against REST-style bot login
([4e00860](4e00860))
* **ci:** compare release PR author against REST-style bot login
([#481](#481))
([75a16ea](75a16ea))
* **ci:** trigger release PR auto-merge via workflow_run instead of
pull_request
([e7eff48](e7eff48))
* **ci:** trigger release PR auto-merge via workflow_run instead of
pull_request
([#479](#479))
([80738de](80738de))
* **eks:** support an optional aws_profile for the kubernetes provider
exec plugin
([#471](#471))
([ccb2f5f](ccb2f5f))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).
sebastiancorrea81 added a commit that referenced this pull request Aug 7, 2026
Small, low-risk change used as a real trigger to test the full
post-merge automation chain (#479, #481,
nullplatform/actions-nullplatform#89) end-to-end on a clean cycle: this
PR's merge → release-please PR → auto-merge (workflow_run + REST author
check + --admin) → tag/release, with no manual step in between.

Root README's usage example pinned `infrastructure/aws/vpc` to
`v1.56.1`, several major versions behind the current `v6.10.0` — updated
so copy-pasting the example doesn't point at a stale tag.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant